\section{Obstacles \& Problems}

	\subsection{Hardware}
		\subsubsection{Chassis}
The limited number of tools available for working metal, made it impossible to proceed with our initial plans for a fully circular design. With thanks to Johan, we eventually settled for an octagon shaped ground plate, mounted on top of the motors: the castor wheel prevented a ground plate mounted below the motors for a lower center of gravity.

Another problem was easier to solve: due to the large metal sides, it turned out to be impossible to connect the power cord. Hence the large hole in one side of the robot.

Finally, due to the castor wheels placement slightly lower on the horizontal plane, the sides of the robot would scrape over the ground in certain configurations. Removing small slices of the sides of the robot easily remedied this, while still retaining the ability to prevent the robot from tipping over.

		\subsubsection{Sensors}
When placing the cameras, they appeared to yield rather unsharp images. Tests were performed to ensure this was not due to covering up of any distance sensors\footnote{Some camera's, like older polaroid versions for example, used sonar sensors to focus} required for focusing. Unfortunately, this did not seem to have any effect and we were forced to conclude that the cameras themselves either lacked proper driver support, or were simply of low quality. 

		\subsubsection{Power supply}
In theory, the robot's power board should be capable of switching between battery and adapter-supplied power seamlessly. In practice however, removing the power cable with an attached battery often resulted in the robot powering down. This behavior persisted even after the battery, power cables and their attachment were replaced. While little more than a nuisance, the problem remained unresolved for the duration of the project.

On another occasion, one battery stopped functioning, and had to be replaced. Another, older battery is suspected of nearing the end of its useful life cycle as well.


	\subsection{Software}
		\subsubsection{Cameras}
One of the major obstacles we encountered was the performance, or more specifically the lack thereof, of the image acquisition and processing abilities of the robots processing unit. During our various tests, image acquisition never exceeded more than 5 frames-per-second (FPS), consuming all available processing power, at a resolution of 640 by 480 pixels. We went to great effort to increase this performance, trying various libraries, drivers and acquisition schemes, without much success; overall, we only managed to boost the camera performance by roughly 30\% compared to its original speed.

Part of the problem was the minimum frame-rate supported by the camera: when image acquisition dropped below 5 FPS, excess frames would be stored in a frame buffer for later use. This in turn resulted in significant delays between when a picture was taken, and when it was made available to the software; we measured delays up to 25 seconds for images taken at high resolution, corresponding to a frame buffer of 5 frames at an acquisition and processing time of 5 seconds each. By lowering the resolution, performing simultaneous processing and updating camera drivers we managed to decrease this delay from 25 seconds to roughly 0.5 seconds for our final robot.

Part of our final solution was to split the camera code into two distinct operating modes, as described in more detail in section \ref{sec:design_sensor}. During exploration, we attempt to find the tags, and thus we need visual information on as large a part of the maze as possible. During this phase, both cameras operate at a low resolution of 320 by 240 pixels. More importantly, image acquisition is done by a separate node, which can run independently of the rest of the robot, so it does not have to wait on the image processing step, while the image processing step does not have to operate on each image taken. 

Instead, only one in every three images taken is send out for processing. This means that, at 5 frames per second (the camera's minimum capture rate), only two images per second are actually processed, which is more than enough to capture all tags as the robot drives past them. 

Since we require higher resolution data for object recognition, the other camera phase was made to perform blocking operations: while it takes a high resolution image and processes it, the robot will not move and instead wait for that operation to finish before proceeding. This was achieved by creating a snapshot service. While it means the robot cannot process images completely in real time, it also means that, with a five to ten second delay when near a tag, it can drive around capturing from two cameras simultaneously without compromising on tag recognition performance. 

		\subsubsection{Behaviors}
The principle idea behind behaviors, is that they should be reactive. A behavior should not create a list of actions to take, and run them all exclusively in one big sequence; doing so would mean other behaviors do not get a chance to act during the sequence of movements, which nullifies the benefit of having simple obstacle avoidance and wall-following behaviors available. However, more complex behaviors are difficult to write completely in a reactive fashion - especially when those behaviors trigger robot states which normally cause other behaviors to perform high-priority actions. 

As an example, the initial exploration behavior would turn the robot to face a wall sometimes, to make sure an image of that wall was captured. However, as soon as the robot faced the wall, the obstacle avoidance behavior would activate and turn the robot away from the wall again. This classical problem was solved by creating non-interruptible movement commands: as long as a behavior sends out "save" motor commands\footnote{In other words, motor commands that should not under any circumstance cause the robot to bump into anything}, the commands from other behaviors may be ignored until they are completed. We spend a considerable amount of time coming up with this solution however, time which may perhaps have been better spend elsewise.






